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(54) Apparatus and method for processing servlets 



(57) A method and apparatus for operating a local 
server computer of a client-server network includes a 
technique to receive a request from a client computer o( 
the client-server network. A determination is made 
whether the request requires dynamically generated in- 



formation from a servlet object of the client-server net- 
work, n so. a specified sen/let object corresponding to 
the request may be uploaded from a remote server com- 
puter of the client-server network. The specified servlet 
object IS then executed to obtain dynamically generated 
information corresponding to the request. 
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Description ^ >i 

Snei Description of ihe inveniion 

This invention reiaEes generally to exchanging mform^ation in a clieni-ser^'er corr!oi;tor environment .Vorc pariic- 
uiarly this invention relates to an improved technique for responcing to mformaiton rccuosis a: a server computer 

BacKarounc of the invention 

Client-server computer networks are well known The most prominent example of a cliont-scrvor computer network 
IS the World Wide Web of computers In a client-server computer network a server computer receives a rcouest lor 
information from a client computer. Web server software operating on the server computer typically retrieves the re- 
quested information from a file stored on a permanent storage device and transmits the file over tne network to the 
client computer thai requested the information, The web server software is generally not written using an object oriented 
programming language Thus, it is not easily extended to provide new functionality Given the dynamic nature of today's 
software marketplace, a product's lack ol flexibility and extondibility can seriously hinder the marketability of the product 

Current web server software can generate a file dynamically in response to a request from a client computer 
Typically, the web server receives the request and then forks a Common Gateway Interface (CGl) process to dynam- 
ically create the file Once the file has been created, the web server software transmits the file back to the client 
computer Unfoaunateiy it is computationally expensive to fork a process each time dynamic information needs to be 
generated 

In view of the foregoing a would be highly desirable to provide a web server which dynamically generates infor- 
mation in response to a client computer request, but which does not incur a process start-up expense while generating 
the dynamic information. Further it would be highly desirable to provide an object oriented web server environment 
that is flexible and extendible. 

Summary of the Invention 

The invention includes a method and apparatus for operating a local server computer of a client-server network. 
The invention includes a technique to receive a request from a client computer of the client-server network. A deter- 
mination IS made whether the request requires dynamically generated information from a ser^let object of the client- 
server network. If so. a specified servlel object corresponding to the request may be uploaded from a remote server 
computer of the client-server network The specified servlet object is then executed to obtain dynamically generated 
information corresponding to the request. 

The servlet objects of the invention provide an object oriented web server environment which is flexible and ex- 
tendible, The client-server network of the invention is populated with the servlet objects The servlet objects operate 
in a continual loop until invoked. Thus there is no startup overhead associated with execution of the servlet objects 
By obsen/ing a common applications program interface, the servlet objects can run in any server environment. A feature 
of the invention allows untrusted servlel objects to be executed in a secure area, with the dynamically generated 
information being passed from the secure area into the remaining server environment. 

Brief Description of the Drawings 

Examples of the invention will now be descnbed in conjunction with the accompanying drawings, in which: 
FIGURE 1 Illustrates a client-server computer network in accordance with an embodiment of the invention. 
FIGURE 2 is a simplified illustration of the interactions between a web server and the sen/lets. 
FIGURE 3 IS a simplified illustration of the interactions between a web server and a sen/let loaded from an external 
server. 

FIGURE 4 illustrates processing steps associated with a servlet processing routine. 
FIGURE 5 illustrates processing steps associated with a servlet processing routine 
Like reference numerals refer to corresponding parts throughout the several views of the drawings 

Detailed Description of the Invention 

Figure 1 illustrates a client-server computer network 20. 

The network 20 includes at least one client computer 22 and at least one server computer 24. The client computer 
22 and the server computer 24 are connected by a transmission channel 26. which may be any wire or wireless trans- 
mission channel. 
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The ciieni computer 22 is a sianaard computer mclucmc a Central Processing Unit (CPU) X connectoa to a 
memory (primary anc/or seconaary) 32. The memory 32 stores a numoer of computer programs, rnciudmg a 'orowser' 
3a As known in the art. a browser is used to communicate v/tth remote sen/er computers 2^ and to visuatiy presen: 
the information received from such computers. The ciient computer 22 establishes network communications tnrougn 
s a standard network connection device 36. 

The server computer 2*i includes standard server computer components, including a network connection cevice 
40. a CPU 42. and a memory (primary and/or secondary) 4^ The memory 44 stores a set of computer programs to 
implement the processing associated with the invention The memory 44 stores a web server 46 The weo server 45 
may be of the type known m the art. which is modified to include tiie additional programs snown tn Figure i That is 
JO in an embodiment of the invention, a standard web server 46 is modified to include a server acceptor threao 45. a 
connection queue 50. a pool administrator 52. a thread pool 54. sen/lets 55. a serviot map 5=. a security acmimsiratcr 
60. and boundary servtets 62. 

Figure 2 is a simplified illustration of a server computer 24A constructed in accordance with an em.bodtment of tno 
invention The figure shows a web server 46 interacting with a set of servlets 56A-56N. In particular the web server 
'5 46 interacts with the servlets through an application program interface (API). As inatcated m Figure 1. the web server 
46 and the servlets 56 are stored m memory 44 The web server 46 may be standard web server software that is 
modified to include the functionality described herein. Each servlei 56 is a piece of software code which is used to 
dynamically generate information. Eacn servlet 56 is an instantiated software object waiting to be invoked. Once it is 
invoked, it dynamically generates information. Note that this technique of dynamically generating information is distinct 
20 irom the typical process of fetching static information from a permanent storage device. The technique of the invention 
IS similar to a CG! script in the sense that it dynamically generates information. However, unlike a CGI script, a servlet 
object o( the present invention is instantiated at server stan-up. Thus, the servlet can be thought of as operating m a 
continual loop waiting to be executed. Observe that after instantiation there is no computational start-up expense when 
the servlet is called. 

2S Figure 3 is a genera! illustration demonstrating additional features of the invention. Figure 3 illustrates a local server 

computer 24A which receives a request from a client computer (not shown) over transmission channel 26. The web 
server 46 determines that dynamically generated information from a servlet object is required. In this case, the servlet 
object is not initially on the local server computer 24A. thus it is uploaded by the local server computer 24A from a 
remote server computer 24B using communication link 26. In the example of Figure 3. servlei 56P is passed from the 

^0 remote server computer 24B to the local server computer 24A. 

Figure 3 illustrates another feature of the invention. In particular it illustrates that the uploaded servlet 56P is 
executed in a security area 57 of the local server computer 24A After execution, the results are passed to a boundary 
servlet 60 in the remaining portion of the local server computer 24A. This security feature allows untrusted servlets to 
be safely executed. 

The foregoing discussion provides a general description of the features and benefits of the invention. Attention 
now turns to a more detailed description of these features and benefits. The left side of Figure 4 illustrates processing 
steps associated with an embodiment of the invention. The right side of Figure 4 illustrates program components that 
may be used to execute these operations. 

The first processing step shown in Figure 4 is to determine whether a new request has been received (step 70). 
-0 As indicated above, a request is a request for information from a client computer 22 lo a sen/er computer 24. The 
operation of a client computer 22 requesting information from a server computer 24 is well known. It is typically per- 
formed using a Uniform Resource Locator or URL A URL specifies a computer and a file. A typical URL is hltp://SU/ 
123. This URL is an instruction to relneve the file "123* from the Slate University computer 'SU' using Ihe Hypenext 
Transfer Protocol 'HTTP'. 

-'5 As shown in Figure 4. a server acceptor thread 46 is used to process each new request. Preferably, the invention 

is implemented as a conneclion-orienled web sen/er with a server acceptor thread lhal continually loops while accepting 
requests. Once a request is received, it dispatches the request lo a connection queue (step 72). As shown in Figure 
1 . the connection queue 50 is formed in the memory of Ihe local server computer 24. 

If no new request is received, then a check is made to determine whether the queue is empty (step 71). If the 

50 queue is not empty or a new request has been received, processing proceeds lo step 74. Step 74 entails thread pool 
administration operations, which are executed by a pool administrator 52. Figure 1 illustrates a thread pool 54. The 
thread pool 54 is a pool of threads that are used for request processing. Individual threads fetch and process requests 
from the connection queue 50. The pool administrator 52 operates to ensure thai there is a thread for each request in 
the connection queue 50. The pool administrator 52 creates or forks additional threads to handle new requests in the 

55 connection queue 50. U a maximum number of threads is reached, the pool administrator 52 blocks new requests from 
entering the connection queue 50. In such a case, the server computer does not receive new requests. On the other 
hand, if a thread has been waiting more than a predetermined period of time for a request from the connection queue 
50. then the pool administrator 60 will destroy it. Preferably, a new handler thread is created using the buffer space of 
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a destroyed handler thread tn other words the invention ts prelerabiy fmpiemenied by using a soecific ouu'er me.'r.orv 
soace ior a thread. When a thread is oes! roved, the buffer memory sc-ace is cleared but it is assigned to a no'.v jhreac 
3y reusing allocated memory m this manner this emoodiment of the invention m!nimt£9S the amount of memory used 
by the system, especially when compared to systems whicn allocate and deallocate memory on a oer recuest basis 
Alter the thread pool administration operations are perform.ed (step 74) a thread retrieves a recuest from the 
connection queue (step 75) The thread then maps tne request toa servlet name (step 7c) The servlei may be specified 
by a URL in which case the mapping process is direct On the other hand some translation process may oe roauiro:: 
to identify which servlet will be able to service the request The mapping operation may bo oertormed in one of the 
following ways A server administrator m^y specify that some kinds of client requests always map to a paaicuiar SQr\f\Q\ 
for example one which talks to a particular database A server administrator may specify that part of the ciiont request 
IS the name of the servlet. as found in an administered servleis directory At many sites, that directory would be shared 
between servers which share the load of processing for the site's clients Some servers may bo able to auiom.aticaily 
invoke servlGts to filter the output of other servleis. based on their administrative configuration For example particular 
types of servlet output may trigger post-processing by other servfets. perhaps to perform format conversions Properly 
authorized clients may specify the servlet to be invoked, without administrative intervention 

Security operations may also be performed by the thread {step 30). A security administrator 50 may be used to 
identify trusted and unirusted classes of servlets The decision to trust a servlet may be established by a set of rules 
associated with the security administrator 60 For example, the security administrator 50 may decide to trust all local 
servlets and mistrust alt uploaded network servlets Untrusted servlets are then executed in the security area 57 as 
shown in Figure 3 The secuniy administrator 60 may also be used to determine if the servlet is authorized to perform 
predetermined rtsky operations Security information of this type may be stored in the thread 

JAVA servlets in accordance with the invention provide strong security policy support This ts because all JAVA 
environments provide a Security fVlanger which can be used to control whether actions such as network or file access 
are to be permitted. By default, all servlets are unirusted and are not allowed to perform operations such as accessing 
network services or local files. However, servlets "built into" the server, or servlets which have been digitally signed as 
they were put into JAVA Archive files, may be trusted and granted more permissions by the security manager. A digital 
signature on executable code indicates that the organization which signed the code "vouches for if in some sense 
Such signatures can't support accountability by themselves, but they do indicate a degree of assurance that may be 
placed on use of that code. For example, a particular signature from an MIS organization might be required on all code 
which is granted general access to network services within a corporate intranet. That signature might only be used on 
code which is strongly believed not to violate particular security policies. Extension APIs tn other languages, such as 
C or scripting languages, can't support such fine grained access controls even if they do allow digital signatures for 
their code. 

After security operations are performed {step 80). the thread is dispatched (step 82 of Figure 5) The dispatch 
operation entails invoking a servlet so that it generates the requested dynamic information The dispatch operation ts 
one of two types. A decision is made to determine whether the sea/let is local (step 84). If the servlet is local, then the 
local sen/let is executed {step 55). This results in the generation of dynamic information that is then processed by the 
web server 46 in a standard manner The web server 45 typically passes the information back to the client computer 
using known techniques. The exchange of information between a servlet and the web server 46 is achieved through 
an application program interface, which is described below. 

If the sen/let is not local, then it is uploaded from a remote server 24B (step 68). A decision is then made regarding 
whether the uploaded servlet is safe (step 90). Recall that the security operation step resulted in the thread acquiring 
information regarding security parameters for servlets. If there are no security problems associated with the uploaded 
servlet. then it is executed locally (step 92). On the other hand, if a security problem is identified, then the servlet is 
executed in a security area (step 94). Thereafter the dynamically generated results are passed to the non-security 
area {step 96). A boundary servlet may be used for this purpose. The boundary servlet may be implemented through 
the use of stubs and subcontracts or through other 'fire wall" techniques known in the art. After the servlet is executed, 
processing returns to step 70 of Figure 4. 

The operation of the invention has now been fully described. Attention now turns to a more particular discussion 
of the servlet objects that are used in accordance with the invention and an embodiment of the application program 
interface used in connection with the servlet objects. As indicated above, the servlet objects are objects are software 
objects that are used to dynamically generate information. They are instantiated objects that sit in a loop wailing to be 
invoked. Preferably, they are implemented as object bytecodes in the JAVA^" programming language. II is well known 
that the JAVA^" programming language is used to implement 'applets" on a client computer An "applet' is executable 
JAVA object bytecodes that are used to generate a graphical display on a client computer The servlets embodying the 
present invention are executed on the server side and do not have graphical content. 

A servlet is typically instantiated on server startup. In the alternative, the servlet may be instantiated under a 
predetermined set of conditions or by client invocation. The servlet may be instantiated and executed by using its URL 
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(e c hitp //host' < servl9[ UjnL>) 'ho hup protocol suppons ine oassmg o' arguments inus argumonrs .-nav ce r-assec 
to the servlet (e g htip./Vnosi/ < serviot URL>'^< argumenis >1 The arcperues cojec: ts a JAVA procra.T:.'TuTig far.guace 
propertres Class whrch comprrses a set of "name'value" oairs A system acmmistraior can pass arg-jments to an m- 
siantiaied HttpServiet ob|eci through the properties object in this way tne system acmimstrator can 'customize' an 
HttpServlet for a particular server at a particular site ."or example the system, acmrnisiraior can pass tne Htiosorv'ie: 
obiect stte specific mform.ation about ine network location of a database wmch stores dccumenis mat will bo rocuosioc 
by client processes across the network or the amount of memory availaote in system ouffors wmch wrll bo usee lor 
processing the ser^/er aaministrator. 

Once tnstanttated. a servlet loops until the server is shut off or a destroy method is called on the serviot by tne 
server Since the servlet operates in a continual loop as ii waits for requests to act upon the server computer avocs 
the overhead of creating and oestroymg the servlet between requests to the servlet. in acoition. keeping sorvleis alive 
between requests allows servlots to pass data and communicate amongst themselves For example scrvlets can 
maintain data about a user between sessions by the user This data can bo shared among different scrvlets m order 
to customize a working environment within which the user works If servlets were created and destroyed on a per 
request basis, it would be much more difficult, if not practically impossible, for a servlet to unoersiand the environment 
within which it runs and utilize this knowledge to provide improved processing capabilities The server computer can 
call a destroy method on the servlet when some resource lima in terms of time memory etc is reacned 

The servlet application program interface (API) establtsnos a standard for interfacing scrvlets with information 
servers, such as web servers The servlet API contains methods for initializing a servlet. processing the request, getting 
servlet information, and destroying the servlet. The servlet API allows platform independent servlets .An example 
servlet interface is as follows 

Servlet interface: 
interface HttpServlet { 

Initialize (ServletContext, ScrvcrProf)crties); 

Service(HttpRequest. HttpResponse); 

Destroy 0; 

} 

The server computer passes objects that implement the 'HttpRequesiV while the servlet returns an "HttpResponse" 
object. The "ServletContext" interface is used to exchange information with the server environment. Some of the meth- 
ods on the 'ServletContexf object are "GetserverO" and "GetServletsO". "GelServer" returns a pointer to the parent 
server within which the instantiated Httpservlet runs. Using this pointer, the HttpServlet object can find out information 
about its parent server. The "GetServief method returns pointers to the servlets running on the parent server. The 
"ServerProperties" interface is used to exchange information regarding specific server properties established by a 
server administrator 

Servlets support the familiar programming model of accepting requests and generating responses. The following 
is a simple servlet defining a single method called 'service" " 
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impon java.servlet.*; 

public class MyServlet extends GenericServlet { 
public void service ( 

Sep/letRequest request, 
ServieiResponse response 
) throws ServleiException, lOException 

{ 
} 



} 

The service meihod is provided with Request and Response parameters. These parameters encapsulate the data sent 
by the client thereby allowing servlets to report status information, such as errors Servlets normally retrieve most of 
their parameters through an input stream and send their responses using an output stream 

ServletlnputStream in = request. geilnpulStream () 
ServletOutputSlream out = response, gelOutputStream (): 

These input and output streams may be used with data m whatever format is appropriate. For example an applet and 
servlet might exchange data using object serialization. HTML, or any number of imago formats. 

Since servlets are JAVA objects, they have instance-specific data. This means that in effect servlets are independ- 
ent applications running within servers, without needing the complexity of additional classes (which are required by 
some alternative server extension APIs). Servlets have access to some servlei-specific configuration data at initiali- 
zation lime. This allows different instances of the same servlet class to be initialized with different data, and be managed 
as differently named servlets. The data provided at initialization time includes an area where each instance keeps its 
persistent instance-specific state. 

Building upon the previous simple servlei examples, the following program code is an example of a servlet that is 
used to send Hypertext Markup Language (HTML) text when il is invoked: 
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public class SimpleServlet extends GenericServlet { 
public void service(ServletRequest req, Sen^letResponse res) 
throws ServlelException, lOException 

{ 

res.selContentTypeC'text/himl"); 

PrintWriter out = new PrintWriter(res.getOutputStrcam()); 
out.println('*<HEAD> < TITLE > SimpleServ'iet Output 
< /TITLE > </HEAD> <BODY>"); 

out. printing < hi > SimpleServlet Output </hl>"); 
out.println("<P>This is output from SimpleServlet."); 
out.println("</BODY>"); 
out.flushQ; 

} 

public String getServletlnfoQ { 

return "A simple servlet"; 

} 

} 

The following program code is an example oi a servlet that uses the finger protocol to query information about 
users on specified host computers. The query string parameters < tl > user < /it >. < tt > hosts < /tt >. and < tt > verbose 

< n\ > can be used to specify the user and hosts to query The parameter <tt> user </tt> is the user name. <tt> hosts 

< /It > is a comma-separated list of host names to query, and <tt> verbose </tt>. if specified, will cause verbose output 
to be generated. For example. <pre> http/goa/finger.html?user=dac&hosts=eno.doppio&verbose=yes </pre> will re- 
quest full information about user "dac" on both hosts "eno" and "doppio". 

JO 
-•5 
50 
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public 

class FingerServlet extends GenericServ'let ( 

* Port number for finger daemon, 
static final int FINGER_PORT = 79; 

* Handles a single finger request from the client. 

public void service(ScrvletRequest req, ServletResponse res) 
throws ServletException, lOException 

{ 

String user = req.getParameter("user"); 
String hosts = req.getParameter("hosts"); 
String verbose = req.getParameter("verbose"); 
res.setContentType("text/htmr'); 

PrintStream out = new PrintStream(res.getOutputStreamQ); 
out.printlnC <html> "); 

out.println(" < head > < title > Finger Servlet < /title > < /head > "); 

out.println("<body>"); 

out.println(" < h2 > Finger results: < /h2 > "); 

outprintln(" <pre> 

if (hosts == null) { 

finger(out, user, null, "yes".equalsIgnoreCase(verbose)); 
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} else ■ { 

SuingTokeniier st = new StringTokenizer(hosts. "."); 
while (st.hasMoreTokcnsQ) { 

Siring host = si.nextTokenQ; 

out.printlnd" + hosl + "]"); 

try { 

fingcrCout. user, host, 

\ves\equaJsIgnoreCasc(verbose)); 

} catch (lOException c) { 
out.println(c); 

} 

out.printlnO; 

} 

} 

out.println(" </pre> **); 
out.println(" </body> </html> "); 

} 

/« 

* Sends finger output for a user and host to the specified output 

* stream. 
*/ 

void finger(OutputStream out, String user, String host, boolean verbose) 
throws lOException 

{ 

// open connection to finger daemon 
Socket s; 

if (host = = null) { 

s = new Socket(InetAddress.getLocalHost(), 

FINGER_PORT); 

} else { 

s = new Socket(host, FINGER_PORT); 

} 

// send finger command 
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PrintStream ps = new PrintStream(s.getOutputStream()); 
if (verbose) { 

ps.printCVW); 

} 

if (user ! = null) { 
ps.print(user); 

} 

ps.print("\r\n"); 
ps.flushQ; 

// copy results to output stream 
InputStream in = s.ge(InputSiream(); 
byie[] buf = new byte [512]; 
int len; 

while ((len = in.read(buf, 0, buf.length)) != -1) { 
out.write(buf, 0, len); 

} 

s.closeQ; 

} 

} 

Those skilled in the art wili appreciate that servtets which are being used with the HTTP protocol may support any 
HTTP method, including GET. POST HEAD, and more. They may redirect requests toother locations and send HTTP- 
specific error messages. They can gel access to parameters which were passed through standard HTML forms, in- 
cluding the HTTP method to be performed and the URI. which identifies the destination of the request. 

As indicated above, one of the biggest performance features of servlets is that they do not require creation of a 
new process for each request, in most environments, many servlets run in parallel within the same process as the 
server. When used in such environments with HTTP servlets provide compelling performance advantages over both 
the CGI approach and the Fast-CGI approach. This is because servlets have a small computational expense during 
thread context switches. Since in most environments servlets can handle many client requests each time they are 
initialized, the cost of the initialization is spread over many methods. All the client requests to that service have the 
opportunity to share data and communications resources, benefitting more strongly from system caches. 

Those skilled in the art will appreciate that the servlets embodying the invention can be used to dynamically extends 
Java-enabled servers. The servlets provide a general framework for services built using the request-response para- 
digm. The servlets can provide secure web-based access to data which is presented using HTML web pages and they 
can be used for interactively viewing or modifying that data using dynamic web page generation techniques. 

The servlets embodying the invention may be used to provide customized multiuser services for customer bases, 
The servlets are also flexible enough to support standardized services, such as serving static web pages through the 
HTTP (or HTTPS) protocols, and proxying services. Since they are used for dynamic extensibility, they may be used 
in a plug-in style, supporting facilities such as search engines and semi-custom applications, such as web-based order 
entry or inventory systems. 

Although the servlets are preferably written in JAVA, the servlet clients may be written in any language. When 
servlets are used in the middle tiers of distributed application systems, they can in turn be clients to other services, 
written in any language. 
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Those skilled m the art will apcrectate mat servlets rr.ay be usee m several moces. The basic mode is at me core 
of a reauest/response proiocol in addnton servlets may oe specialized to suoport protocols sucn as HTTP in HTTP 
based apoltcaiions. servlets are ponable. complete, and mucn more eHicieni replacement for CGI basec extensions 
Also in HTTP applications, servlets may be used wim HTML server side induces to dynamically generate part of a 
weo cocumeni 

The foregoing aescription. (or purposes of explanation, used specific nomenclature to provice a thorough unaer- 
standing of examples of the invention However, it will bo apparent to one skilled in the art that the specific aetatts are 
not required in order to practice other examples of the invention. In otner instances, well know circuits and Devices are 
shown in block diayram form in order to avoid unnecessary distraction from the unaerlymg principles Thus, the fore- 
going descriptions of specific embodiments of the present invention are presented for purposes of illustration and 
description 



Claims 

1 . A method executed by a local server computer under the control of a program, said local server computer including 
a memory for storing said program said local server computer forming a portion of a client-server network, said 
method comprising the steps of: 

receiving a request from a client computer of said client-server network: 

determining that said request requires dynamically generated information from a servlet ob|eci of said client- 
server network: 

uploading from a remote server computer of said client-server network a specified servlel object corresponding 
to said request: and 

executing said specified servlet object to obtain dynamically generated information corresponding to said re- 
quest. 

2. The method of claim l further comprising the step of passing dynamically generated information from said specified 
servlet object to a web server operating on said local sen/er computer said passing step being facilitated with an 
application program interface. 

3. The method of claim 2 wherein said application programming interface specifies techniques for performing at least 
one of the following operations: initializing a servlet object, executing a servlet object, and destroying a servlet 
object. 

4. The method of claim 2 wherein said specified servlet object and said application program interface are specified 
as object bytecodes in the JAVA programming language 

5. The method of claim 2 further comprising the step of sending said dynamically generated information from said 
web server to said client computer 

6. The method of claim 1 wherein said executing step includes the steps of 

executing said specified servlet in a security area of said local server computer: and 

passing said dynamically generated information from said security area to a non-security area of said local 
server computer 

7. The method of claim l wherein said local server computer stores a plurality of servlet objects, each of said servlet 
objects continuously operating until invoked in response to a specified request from a client computer 

8. The method of claim 7 wherein said plurality of servlet objects pass data to one another. 

9. The method ol claim 7 wherein said selected servlet objects of said plurality of sen/let objects are Instantiated at 
the start-up of said local server computer 

10. The method of claim 7 wherein selected servlel objects of said plurality of sen/let objects are instantiated in re- 
sponse to a demand from said client computer 
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11. The method of ciatm 7 v^herem seleciec ser/ie: cb|ecis of saic pijraliiy oi servle; cojecis are mstaniiated in ro- 
sponse to an aciivateo servlei URL 

12. The meinod of claim n wherein sac servlet URL includes arguments 

5 

1 3. The meinod of claim i wherein said receiving siep includes the step of siorioc sate roauosi m a connection queue 

1 4. The method of claim 1 3 wherein said determining step includes the step of selecting a nandier tnroad from a pool 
of handler threaos to execute said determining sieo 

10 

15. The method of claim 14 further comprising the step of operating said pool of handler threaos by selectively creating 
a new handler thread and destroying an old handler thread 

16. The method of claim 15 wherein said operating step includes the step of rousing a buffer memory space of said 
'S old handler thread for said new handier thread 

17. A computer readable memory that can be used to direct a server computer of a client-server computer network to 
function in a specified manner, comprising 

^0 a first set of instructions to receive a request from a client computer of said client-server network 

a second set of instructions to determine that said request requires dynamically generated information from 
a servlei object of said client-server network; 

a third set of instructions to upload from a remote server computer of said client-server network a specified 
servtel object corresponding to satd request, and 
2S a fourth set of instructions to execute said specified servlei ob)eci to obtain dynamically generated information 

corresponding to satd request. 

18. The apparatus of claim 17 further comprising a fifth set of instructions to pass, through an application program 
interface, dynamically generated information from satd specified servlet object to a web server operating on satd 

^0 local server computer. 

1 9. The apparatus of claim 1 3 further comprising a sixth set of instructions to pass said dynamically generated infor- 
mation from said web server to said client computer 

35 20. The apparatus of claim 1 7 further comprising a seventh set of instructions to store a plurality of servlet objects on 
satd server computer each of said servlet ob|ects continuously operating until invoked tn response to a specified 
request from a chent computer 

21. The apparatus of claim 20 wherein said seventh set of instructions include instructions to pass data between said 
-0 plurality of servlet objects. 

22. A computer readable memory that can be used to direct a server computer of a client-server computer network to 
function in a specified manner, comprising: 

a first set of instructions to receive a request from a client computer of said client-server computer network, 
a second set of instructions to determine that said request requires dynamically generated information from 
a servlet object of said server computer: 

a third set of instructions to execute said specified servlet object to obtain dynamically generated information 
corresponding to said request: and 

a fourth set of instructions to pass said dynamically generated information to said client computer. 

23. The apparatus of claim 22 wherein said second set of instructions include instructions to interpret a servlet URL 
corresponding to said request. 

24. The apparatus of claim 22 wherein said second set of instructions include instructions to interpret a servlet URL 
with arguments. 

25. The apparatus of claim 22 further comprising a fifth set of instructions to store a plurality of servlet objects on said 
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server compuier eacnol said serviet objects conunuousiy coeraung uniii snvokec in response toa S3ec:/ier recues: 
from a client computer 

26. The apparatus of claim 20 wherein said (ilth set o( instructions include instructions to pass ca-a ceiween saic 
plurality of servtet objects. 

27. A citent-sen/er computer network comprising 

a client computer to generate a roquosi; and 
a server compuier to 

determine that said request requires dynamically generated inform.ation from a servlci coicct of sate server 
computer. 

execute said specified servlel object to obtain dynamically generated information corresponding to said 
request, and 

pass said dynamically generated information to said client computer. 

28. The apparatus of claim 27 further comprising a remote server computer storing a set of serviet ob|ects that can 
be passed to said server computer. 

29. The apparatus of claim 27 wherein said sen/er computer stores a plurality of sefvlet ob)ecis. each of saio serviet 
ob)ecis continuously operating until invoked in response toa specified request from said client computer 

30. The apparatus of claim 29 wherein said plurality of serviet objects pass data between themselves. 



13 



EP 0 810 524 A1 



20 

\ 



.26 



L 



22A 



30 



1 



Network 
Connection 



CPU 



T 

36 



32 



Browser 



o 
o 
o 



34 



r 



24A 



Network 
Connection 



40 



42 



CPU 



44 



X 

I 

T 



Web Server 



Server Acceptor Thread 



Connection Queue 



Pool Administrator 



Thread Pool 



Servlels 



Servlet Map 



Security Administrator 



Boundary Servlets 



o 
o 
o 



Figure 1 



14 



a 



EP 0 810 524 A1 



^24A 



Web Server 




56N 



Figure 2 



IS 



EP 0 810 524 A1 




Figure 3 



16 



EP 0 810 524 Al 




Store Request 
in Connection 
Queue 



JL r 



74 



Thread Pool 
Administration 



76 



Release Thread/ 
Retrieve Request 



▼ r 



78 



Map Servlet 
Name 



■80 



Perfornn 
Security 
Operations 



Server Acceptor 
Thread (48) 



Server Acceptor 
Thread (48)/ 
Connection 
Queue (50) 



Pool 

Administrator (52) 



Thread from Thread 
Pool(54) 



Thread from Thread 
Pool (54)/Servlet Map (58) 



Security 

Administrator (60) 



(To Step 82; Figure 5) 



Figure 4 



17 



EP 0 810 524 A1 



(Fro.T Step £0: Figure 
-S2 



No 



r 



83 



Upload Remote 
Servlet 




Execute Servlet 
Behind Wall 



96 



Pass Results 
to Boundary 
Servlet 



Dispatch 
Thread 




Yes 



T r 



92 



Execute Servlet 
Locally 



r 



86 



Execute Local 
Servlet 



(To step 70: Figure 4) 



Figure 5 



BNSOOCIOrSP 0910524AI> 



18 



EP 0 810 524 A1 



J) 



Kuropcan I'aicni 



EUROPEAN SEARCH REPORT 



Appiivitiun >unt&v 

E? 97 30 3576 



DOCUMENTS CONSIDERED TO BE RELEVANT 



Cit;itJon of docvm^ni fUh indic*uon. »»hcrc appropnaic. 
of rrlcv^nt p^iw-jgCN 



i Rclc\i»n( j ClASSUK'AflU.N UK IMK 



NETSCAPEWORLO, 

5 May 1997, XP002041555 
jiM LOWE: "How Java servlets can replace 
CGI scripts - for ease, perfonnance & 
mere" 

(hLiD://www.cs.berkeley .edu/*padmanab/pape 
rs/masters-tr,ps) 

(http://www.netcapeworld.com/neiscapeworld 
/nw-05- 1997/nw-05-bytecode.html ) 

• the whole document * 

NETSCAPEWORLD. 

- a July 1996 XP0G2041556 
TRISHA GORMAN: "Server-side appHets in 
Java generate developer anticipation" 
(http; //www. net sc3peworld.com/netscapeworl 
d/nw-07-19S6/mw-07-jeeves.html ) 
" the whole document * 

UNIVERSITY OF CALIFORNIA AT BERKELEY 
; REPORT NO. UCB/CSO-95-875 , 
I Hay 1995, COMPUTER SCIENCE DIVISION, 

oages 1-24, XP002041557 

VENKATA N. PADMANABHAN: "Improving World 
wide Web Latency" 

{http://www.es .berke ley. edu/"padmanab/pape 
rs/masters-tr.ps) 

• aostract * 

• page 8, paragraph 2 - paragraph 3 ' 



■/-- 



ii-30 



1-30 



1.17,22, 
27 



G06F9/46 



SKAH(IIKn llni.U.ei 



! G06F 



I 



ITte prevent search rtpurt b^^ hcen drii»«n up for alt d;4ini> 






THE HAGUE 


23 September 1997 


Fonderson, A 



CAfLCORY ()K rrru) not i;mkn is 

\ : psjficulirly reirrint if taken alone 

Y : farticulutj rrtvvani if combinM »ith another 

Cooimtnt of (h« ^ant category 
^ : tcchnalftit*cal bickr*^nd 
U : nufl-wnttat disdotare 
P : intcmcdUte 4ncumrti 



T : iti<nr> or pnnaplc tiodcrl|inK (he ic^^tinn 
t : earlio- pitttit 4ocun<nt. puWtthH on, nr 

iftcr ihc Tiltne date 
I) : document cited in tA« appticstion 
L : ducumvot atcd lur uittcf roititu 



A : re«ni6«f ot the lane patent tamity. coervfpondi&K 
docuaeni 



19 



EP 0 810 524 Al 



J) 



Kuropcaii Patcni 



El ROPEAN SEARCH REPORT 



EP 97 30 3576 



DOCL'MENTS CONSIDERED TO BE REL£\ AiN'T 



C»tc;on 



Citufion nf dorumrni with indicutinn. whcrr uppmprijic, 
of relevant pasvago 



to rii^iffl 



FIFTH INTERNATIONAL WORLD WIDE WEB 
CONFERENCE (POSITION ?^?ER FOR THE 
WORKSHOP "PROGRAMMING THE WES - A SEARCH 
FOR API 'S". 

6 May 1995, PARIS, FRANCE, XPOO204155S 
MARK R. BROWN: "FastCGI : A 
High-performance Gateway Interface" 
(http: //www. fastcgi .com/ki t/doc/www5-api -w 
orkshop . html ) 
* the whole document * 

IBM TECHNICAL DISCLOSURE BULLETIN, 
jvol. 38, no. 5, May 1995, NEW YORK US, 
I pages 199-200, XP002041559 "Control of 
■Dynamic Threads Pool for Concurrent Remote 
I Procedure Ca 1 1 s" 
I* the whole docun>ent * 



1,17,22 
27 



n.ASMtK Alios or inr 

U't'LK KllOy iliH.t 1.6) 



14,15 



It( l(M( AJ. HLt.US 
S»:aK<I(KI> (Inf.t 1.6t 



The prnvnt sc^ ch report ha^ been drawn up for ail d^ms 



THE HAGUE 



23 September 1997 



Fonderson. A 



CAIKOORVOF t lltl) UOtt.%(KMS 

X ; pviiculiH> relevant If taktn tlont 

\ : pviicular1> rct«^2n1 tf cuabui^ with mother 

4 : tectinolociciJ bickifrouiv^ 

P : tntermcdute docitraent 



I : theory or prmapl« un4«rivin^ ihc invention 
K <art<(7 piioit document, but ptthlithe^ nn, nt 

iftcr th« fill at 4at< 
1) : ducumcni dtW in ih« application 
1. : ditcumrat attt toe nthft ra\nn% 

Si : mombcr ot the tine pitcitt fanily, corrcspoodiny 
document 



BEST AVAILABLE COPY 



20 



BNSDOCID-<E» 08i052iAi> 



